home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_1599 / 1440 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  1.5 KB
  1. From: Claus Brod <clausb@hpbeo79.bbn.hp.com>
  2. Subject: Re: Just a couple of things.
  3. Date: Tue, 24 May 94 9:12:26 MESZ
  4. In-Reply-To: <9405210013.AA00681@jelal.north.de>; from "Juergen Lock" at May 21, 94 2:13 am
  5. Mailer: Elm [revision: 70.85]
  6.  
  7. >  hmm, sure?  if we just want IO to halt only processes which are in a
  8. > disk IO systemcall (as opposed to `halt _every_ process' like its now...)
  9. > then we don't need real multithreaded filesystems yet, and i don't think
  10. > the kernel needs much more reentrancy than now like when a process
  11. > sleeps for tty IO.  and the SCSI interrupt handler could just reset
  12. > its in-service bit and ipl and then addroottimeout()?
  13.  
  14. I tried similar things, and no, it won't work. The situation is as
  15. follows:
  16.  
  17. - Process A calls GEMDOS to read a file.
  18.  
  19. - GEMDOS calls BIOS to read a block.
  20.  
  21. - HD driver initiates transfer, puts process A to sleep. Note that
  22.   process A is now sleeping *inside* GEMDOS.
  23.  
  24. - Process B makes a GEMDOS call.
  25.  
  26. Similar scenarios are possible for VDI and AES calls which in turn
  27. call GEMDOS (vst_loadfonts, rsrc_load...).
  28.  
  29. The most simple solution would be to block any GEMDOS call when
  30. another process already is in GEMDOS. This would at least allow
  31. other processes to use the CPU or call (X)BIOS. Better than
  32. nothing.
  33.  
  34. --clausb@hpbeo79.bbn.hp.com-----------------------------------------------
  35. Claus Brod, MDD, HP Boeblingen         Have you hugged your manager today?
  36. --#include <std_disclaimer>-----------------------------------------------
  37.